sourcemap: fix the CRLF peek when counting generated lines - #38449

Problem

• Every mapping that follows a carriage return in the printed output lands on the wrong generated line, in both bun build --sourcemap output and the maps the runtime uses to remap error.stack: a lone \r followed by a one-character line is not counted as a line break, and an actual \r\n is counted as two.
• Repro: bundle /*! a\rb\nc */\nconsole.log(1);\nthrow new Error("x");\n with --sourcemap=external. The output puts console.log on its 5th line (the \r ends a line, as it does for every JS engine), but mappings is ;AAGA;AAAA;AAAA,QAAQ,IAAI,CAAC;..., with console.log in the 4th line group. Running a file with that comment reports a new Error() created on line 4 as line 5.
• Cause: update_generated_line_and_column_slow in src/sourcemap/Chunk.rs advances i past the decoded character before matching on it, but the \r arm peeked at last_generated_update + i + 1, which is two bytes past the CR. (The + 1 is from esbuild's version of this loop, where i is the index of the rune itself.) So \rX\n skips the CR because the byte two ahead is a \n, and \r\nX counts the CR and then the \n again.

Fix

• The \r arm peeks at slice[i], the byte directly after the CR. That condition is the whole change; the rest of the hunk is the comment.
• This is the line terminator rule JSC uses for the positions that get looked up in these maps (\r, \n, U+2028 and U+2029 each end a line, \r\n ends one), and it is the rule LineOffsetTable::generate already applies to the original side of every mapping, so the two sides of a mapping now count lines the same way.
• This miscount is what Sourcemap reported location in browser does not match actual location #18814 ran into (CRLF legal comments in tabster's dist shifted every later mapping in the bundle, one line per comment line); Ensure we add sourcemappings for S.Comment #23871 fixed that report by rewriting \r\n to \n inside legal comments in the printer, which left the builder wrong for the CRs that still get through (the shapes tested here). Fixing the peek where the count happens covers those without more printer-side normalization.
• Tests, all of which fail on the unfixed build:
  • test/bundler/bundler_comments.test.ts: three bundles (lone CR in a legal comment, CRLF left in a legal comment, CRLF in an inlined enum member comment) check that the generated line holding each statement after the comment maps back to that statement's line in the entry point. Unfixed, the statement after the lone CR maps to the line below it and the one after the CRLF maps to the line above it.
  • test/js/bun/sourcemap/internal-sourcemap.test.ts: the same two shapes through bun run and error.stack, which go through the same builder but the runtime's internal map format. Unfixed, they report line 5 instead of 4 and line 4 instead of 5.
• Also ran test/js/bun/sourcemap/, bundler_edgecase, the compile source map tests and the node:module source map tests against the debug build.

Background

• The printer calls the source map builder once per token it maps. update_generated_line_and_column scans whatever was printed since the previous call to advance the generated line and column, emitting one line separator (a ; in VLQ maps, a separator entry in the runtime's internal format) per line break it sees. bun build maps and the runtime's stack trace maps both come out of this one loop.
• A raw CR reaches the printed output in two ways. Legal comments (/*! ... */) are copied verbatim except that a \r\n inside them becomes \n, so a lone \r survives and \r\r\n comes out as a real \r\n. Accessing an inlined enum member prints 1 /* member name */ with the name verbatim. Strings and template literals escape or normalize CRs, so the tests use those two shapes.
• The runtime CRLF test uses the legal comment shape rather than the enum one because the runtime prints a single-member enum as an arrow function ending in a multi-line template literal, and JSC reports wrong line numbers after that construct regardless of source maps (tracked separately).
• Not changed here: the same loop (and LineOffsetTable::generate) steps over the declared width of an invalid UTF-8 lead byte, so a Latin-1 byte directly before a newline still swallows that line break. Different cause, tracked separately.

$ printf '/*! a\rb\nc */\nconsole.log(1);\nthrow new Error("x");\n' > in.js
$ bun build ./in.js --outdir out --sourcemap=external

# out/in.js (cat -A)
// in.js$
/*! a^Mb$
c */$
console.log(1);$
throw new Error("x");$

# mappings before (6 groups, console.log in group 4, it is on line 5 of the file)
;AAGA;AAAA;AAAA,QAAQ,IAAI,CAAC;AACb,MAAM,IAAI,MAAM,GAAG;
# mappings after (7 groups)
;AAGA;AAAA;AAAA;AAAA,QAAQ,IAAI,CAAC;AACb,MAAM,IAAI,MAAM,GAAG;

$ printf 'enum E { "a\\r\\nb" = 1 }\nconsole.log(E["a\\r\\nb"]);\nthrow new Error("x");\n' > in.ts
$ bun build ./in.ts --outdir out --sourcemap=external
# out/in.js contains `console.log(1 /* a<CR><LF>b */);` (3 lines of code after the path comment)
# before (6 groups, the CRLF counted twice)
;AACA,QAAQ,IAAI;AAAA;AAAA,IAAW;AACvB,MAAM,IAAI,MAAM,GAAG;
# after (5 groups)
;AACA,QAAQ,IAAI;AAAA,IAAW;AACvB,MAAM,IAAI,MAAM,GAAG;

$ printf '/*! a\rb\nc */\nconst err = new Error("x");\nconsole.log(err.stack.split("\\n")[1]);\n' > rt.js
$ bun rt.js
    at /tmp/rt.js:5:17      # before (the Error is on line 4)
    at /tmp/rt.js:4:17      # after